A software defined network (SDN) is a relatively new type of networking architecture that provides centralized control of network elements rather than a distributed architecture utilized by conventional networks. That is, in a distributed architecture, each network element makes a routing decision based on the results of traffic processing and a distributed control mechanism. In contrast, in the SDN, a network element follows routing decisions received from a central controller. In detail, the operation of a network element can be logically divided into a “control path” and a “data path”. In the control path, control protocols, e.g., for building in routing tables, are operable. In the data path, packet-processing operations are performed. Such operations include examining each input packet and making decisions based on the examination as to how to handle the input packet (e.g., packet forwarding, packet switching, bridging, load balancing, and so on). Furthermore, in a conventional network, network elements typically include both a control plane and a data plane, whereas in a SDN, the network elements include the data path, and the central controller implements the control path.
The SDN can be implemented in wide area networks (WANs), local area networks (LANs), the Internet, metropolitan area networks (MANs), ISP backbones, datacenters, and the like. Each network element in the SDN may be a router, a switch, a bridge, a load balancer, and so on, as well as any virtual instantiations thereof.
In one configuration of a SDN, the central controller communicates with the network elements using an OpenFlow protocol which provides a network abstraction layer for such communication. Specifically, the OpenFlow protocol allows adding programmability to network elements for the purpose of packets-processing operations under the control of the central controller, thereby allowing the central controller to define the traffic handling decisions in the network element.
Traffic received by a network element that supports the OpenFlow protocol is processed and routed according to a set of rules defined by the central controller based on the characteristics of the required network operation. Such a network element routes traffic according to a flow table and occasionally sends packets to the central controller. Each network element can be pre-configured with a flow table and can be modified by the central controller as required. The operation of network elements according to the OpenFlow protocol is further described in the “OpenFlow Switch Specification”, Version 1.1.3, published on Apr. 16, 2012 by Open Networking Foundation, the contents of which are hereby incorporated by reference merely for the useful understanding of the background and without any limitations on the disclosed embodiments.
Thus, the OpenFlow protocol and SDN allow utilization of the hardware speed processing capability of conventional network elements while providing more flexibility in the traffic packet-processing decisions. As noted above, packets-processing operations include, but are not limited to, routing, load balancing, forwarding, switching, and bridging of packets. While the OpenFlow protocol allows the programmability of network elements in the SDN, this protocol does not allow for analyzing the traffic flows through SDN switches and controller. In particular, the currently defined SDN-based protocols (e.g., OpenFlow) are not designed for analyzing application layer (layer-7 or L7) parameters and attributes of the OSI module, but merely currently limited to classification of layer-4 network parameters. Typically, SDN-based switches and controllers can take routing decision based on MAC or network layers (L2 or L3) parameters. For example, the action to apply on each packet can be based on a source IP address and/or a destination IP address.
A significant challenge facing the services providers or network carriers arises due to the ample amount of applications offered to subscribers. Such applications may include video streaming, web browsing, security applications, instant messaging (IM), emails, peer-to-peer communication, mobile applications (“Apps”), and so on. The subscribers may connect to such data services through mobile devices (e.g., smartphones, tablet computers, etc.), laptop computers, desktop computers and the like, through a cellular network, a local area network (LAN), or the web.
Each such application is typically configured with different services per subscriber and/or type of application. Such services may include, for example, security, quality of service (QoS), quality of experience (QoE), parental control, access control, traffic optimization, analytic services, content filtering, and so on.
In order to provide the data services with their assigned provisions, application layer L7 processing is required, for example, to identify the application and/or protocol type associated with the flow of traffic. Furthermore, the application layer (L7) processing is required to take routing decisions per flow. Processing of application layer (L7) traffic demands high network and computing resources. This demand results in some major drawbacks on the utilization available. For example, extensive processing of traffic at the application layer (L7) would result in inefficient use of network bandwidth and computing resources, bottlenecks, and lack of coverage due to inability to rapidly respond to new networking and application requirements, reduced throughput, increased latency, and limited scalability of the network due to limited computing resources. In addition, the data services do not provide feedback regarding their performance. As a result, network paths can potentially be reprogrammed based on the application layer traffic analysis.
Although there are network appliances that are optimized to perform application layer (L7) traffic analysis, such appliances are expensive in terms of cost and utilization of network resources. Therefore, a straightforward approach of increasing the number of appliances is a costly solution that would be adopted by network carriers. Furthermore, the conventional network appliances are not designed to operate within SDNs. Specifically, conventional application layer (L7) network appliances cannot perform steering of traffic over SDNs.
It would therefore be advantageous to provide an efficient solution that provides for steering traffic in SDNs based on minimal processing of application layer traffic.